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REMARKS 

Reconsideration of the application in light of the following remarks is respectfully requested. 
Status of the Claims 

Claims 1-24 are pending. Reconsideration of the rejections is respectfully requested. 
Allowable Subject Matter 

Applicants thank the Examiner for allowing claims 3-8 and 11. 

Rejections Under 35 ILS.C. §103(a) 

Claims 1, 14, 23 and 24 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. Patent No. 6,209,018 to Ben-Shachar et al. ("Ben-Shachar") in view of U.S. 
Patent No. 6,606,643 to Emens et al. ("Emens"). Claims 2 and 9 stand rejected as being 
unpatentable over Ben-Shachar in view of Emens and "JR (Java Reflective Broker)." Claims 10, 12 
and 13 stand rejected as being unpatentable over Ben-Shachar in view of Emens and Arno. Claims 
15 and 16 stand rejected as being unpatentable over Ben-Shachar in view of Emens; U.S. Patent No. 
5,675,795 to Rawson et al. ("Rawson") and U.S. Patent No. 5,452,447 to Nelson et al. ("Nelson"). 
Claim 17 stands rejected as being unpatentable over Ben-Shachar in view of Emens, Rawson and JR 
(Java Reflective Broker). Claims 18 and 19 stand rejected as unpatentable over Ben-Shachar in view 
of Emens, Rawson, Nelson and Arno. Additionally, claims 20 and 21 stand rejected as being 
unpatentable over Ben-Shachar in view of Emens, Rawson, Nelson and U.S. Patent No. 5,742,759 
to Nessett et al. ("Nessett"). 

With respect to claim 1, the Examiner contends that Ben-Shachar discloses all of the 
features of claim 1, except permitting the client to communicate with the server associated with the 
selected object reference which was forwarded to the client's binding table. However, the examiner 
contends that Emens teaches such a step. 

Applicants respectfully traverse the above rejection. Ben-Shachar and Emens, alone 
or in combination, do not teach or suggest all of the features of claim 1 . 
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Applicants previously amended independent claims 1 and 15 to emphasize the 
transparent feature of the invention, specifically calling for the steps of "establishing name service 
clusters for the object servers which each contain a unique object binding table that contains object 
server references [and] in response to a request from a client that invokes a cluster, performing a 
load balance by having the name service select an object server located in the invoked cluster." 
Additionally, the applicants amended the claims to specifically state that ". . . the fault tolerance, the 
load balance and the failover are performed transparently". Neither Ben-Shachar nor Emens, alone 
or in combination, teach or suggest the notion of transparency, and instead explicitly violate the 
technical advance which is part of the present invention. 

The present invention discloses performing load balancing, fault tolerance and 
failover transparently through the use of the CORBA Name Service. Specifically load balancing, 
fault tolerance and failover are carried out within the constraints of the existing CORBA 
communication pattern. There are no changes to the communication patterns or services, and no 
changes to the user, client or server codes. By introducing the notion of transparency, the present 
invention, expressly and purposely constrains itself to the existing CORBA communication pattern 
and does not allow for introduction of new communication models, structures or methods. The 
same is not true of either Ben-Shachar or Emens. Ben-Shachar requires changes to the services 
used in the system, and both Ben-Shachar and Emens requires changes to the client and server codes 
in addition to the functionality prescribed by the standard. Furthermore, Emens does not utilize 
CORBA, and therefore is neither bound nor constrained by it. Therefore, neither Ben-Shachar nor 
Emens teach or suggest performing fault tolerance, load balancing and failover of CORBA object 
servers transparently. 

The Examiner cites Col. 10, lines 3-7 and Col. 11, lines 60-63 to demonstrate that 
Ben-Shachar discloses performing fault tolerance, load balancing and failover transparently. 
However, Ben-Shachar is incapable of performing such functions transparently because instead of 
embedding the functionality of performing the fault tolerance, load balancing and failover into 
CORBA' s existing communication pattern, via the Name Service, Ben-Shachar builds a system on 
top of the existing CORBA infrastructure. Ben-Shachar specifically requires additional 
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infrastructure and services above and beyond the CORBA standard. Such an act automatically 
highlights the lack of transparency because transparency expressly prohibits awareness to a user, 
which is inescapable once features are added to any standard. 

Under the present invention, once an object reference is located, a notion of a cluster 
is introduced in the implementation of the Name Service. Such enables load balancing based on 
multiple object references binding under the same name in the Name Service. The Name Service is 
a standard CORBA infrastructure that most customers are already using. In contrast, Ben-Shachar 
eliminates the standard CORBA Name Service and replaces it with a self created Service Locator, 
which automatically requires the participants to change their existing communication patterns to 
enable the load balancing and fault tolerance. For instance, as previously noted, instead of the client 
talking to the Name Service to obtain an object reference of the server as is the norm, the client of 
Ben-Shachar must now talk to a service locator, create a service, allocate a server and then obtain 
that server. This technique of requiring additional infrastructure, i.e. running the Service Locator 
and/or Service Manager to enable the load balancing and the fault tolerance, creates noticeable 
changes to a user, preventing the performance of the functions in a transparent manner. Therefore, 
clustering inside the Name Service, as in the present invention, is not comparable to clustering 
inside the Service Locator of Ben-Shachar, because now changes to communication 
patterns/services or user/client/server code are not only possible, but are inescapable. 

Ben-Shachar not only fails to disclose the notion of transparency but specifically teaches 
away from it. Ben-Shachar's requirements of building or changing a system to make it load balance 
or fault tolerance aware simply classifies Ben-Shachar as intrusive rather than transparent. Ben- 
Shachar's requirement of the service proxy, service locator, service object and worker all 
cooperating with each other as part of a close knit framework make it impossible to perform the 
load balance and fault tolerance where a CORBA client and server are both unaware of the 
framework. Since the entire system must be built on the framework Ben-Shachar established, load 
balancing and fault tolerance cannot possibly be performed transparently. 
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With respect to claim 15, 23 and 24, applicants repeat the above arguments and submit that 
they define over the prior art for the reasons stated above regarding claim 1. 

With respect to dependant claims 2, 9, 10, 12-14 and 16-24, applicant submit that these 
claims depend directly or indirectly from the independent claims discussed above and should be 
allowed at least for the same reasons discussed for their respective base claims and in view of their 
own further recitations. 

Conclusion 

Each and every point raised in the Office Action dated September 7, 2005 has been 
addressed on the basis of the above amendments and remarks. In view of the foregoing it is 
believed that claims 1-2, 9,10 and 12-24 are in condition for allowance and it is respectfully 
requested that the application be reconsidered and that all pending claims be allowed and the case 
passed to issue. 
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If there are any other issues remaining which the Examiner believes could be resolved 
through a Supplemental Response or an Examiner's Amendment, the Examiner is respectfully 
requested to contact the undersigned at the telephone number indicated below. 

Dated: June 3, 2005 Respectfully submitted, 




Melvin C. Garner 



Registration No.: 26,272 
DARBY & DARBY P.C. 
P.O. Box 5257 

New York, New York 10150-5257 
(212) 527-7700 
(212) 527-7701 (Fax) 
Attorneys/Agents For Applicant 
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